
REMARKS 

Pending Claims: 

In this application, claims 1-6, and 9-23 are currently pending. Claim 1 has been 
amended. Claims 2-6, and 9-20 have not be altered since filing. Claims 7 and 8 have 
been deleted in this amendment. Claims 21-23 have been added. 

Abstract: 

The abstract submitted with the application was objected to in the Office Action. 
The Applicant has amended the abstract to overcome these objections. The applicant 
submits that the abstract as amended overcomes the stated objections. 

Rejection under 35 U.S.C. §102(b) 

Cells (Claims 1-6) 

The Examiner has rejected claims 1-9, 12, and 15-20 as anticipated by Kawai, U.S. 
Patent No. 5,717,924. The office action stated that Kawai describes a collection of data 
cells (Fig. 12a and corresponding text), including a single instance identifier (the 
surrogate key in Fig. 12a), a single attribute type identifier (the foreign key student in 
Fig. 12a), an attribute value (the GPA in Fig. 12a), and the entity identifier (the major in 
Fig. 12a). Furthermore, the office action finds that Kawai reveals a cell set (100 in Fig. 2), 
multiple values relating to a specific attribute type (name, address, soc-sec-no, and 
birthday in 105 and 107 in Fig. 2), only four fields relating to actual data (105 and 107 in 
Fig. 2), with no cells containing the exact same four values (105, 107 in Fig. 2). 

In examining the Kawai reference, the applicant believes that cited text and 
figures do not anticipate the elements set forth in the claims. Claim 1 covers a collection 
of data comprising "a plurality of data cells." The above amendment to claim 1 clarifies 
that each cell is a data construct that contains a single element of data (with claim 4 
clarifying that a data cell can contain "multiple, separate values relating to the specific 
attribute type of the specific instance of the specific entity type"). Thus, in order for a 
reference to anticipate claim 1, the reference must teach a data construct that contains a 
single element of data, and contains the three parts identified as subpart i), ii), and iii) of 
claim 1 (specifically a single instance identifier, a single attribute identifier, and an 
attribute value). Claim 2 adds that the data construct must contain an entity identifier 
value. These elements allow each cell to be "self-identifying," which is vital for the 
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functioning of a data collection made up of data cells, as is explained in the 
Specification: 

Because there is no external construct to associate one cell 100 with another, each 
data cell 100 of the present invention must be self-identifying. In other words, the 
data cell 100 must contain not only the value of interest, but it also must contain 
enough information to identify the attribute to which the value relates, and to 
associate the attribute with a particular instance of an entity. 

Specification, page 7, lines 12-19. The Kawai reference does not disclose or suggest such 
a data construct. 

The Kawai reference teaches a method of translating between a semantic object 
model of a database and a relational database schema. The background of the invention 
section of Kawai discusses the SALSA program that allows a user to define a model of 
the data using semantic objects. SALSA then creates a corresponding relational database 
schema that can store data in the computer. Kawai, col. 1, lines 30-50. The improvement 
in the Kawai patent relates to techniques that allow modifications made to the semantic 
object models to be implemented in the underlying relational database schema without 
completely redefining the schema. Kawai, col. 2, lines 11-34. 

Figure 12a of Kawai illustrates one type of change to a semantic object that could 
be implemented in the database schema. Specifically, Figure 12a shows a "many-to- 
many value type data migration." Kawai, col. 20, lines 31-32. Element 550 is the 
semantic object for a student. This object 550 is directly defined by a user, and contains 
a student_ID component, a name component, a major component, and a year data 
group component. Each of these components contains different attribute values for the 
object 550. The student ID component and name component of object 550 are single 
value components, while the major and year data components are multi-valued. When 
this object 550 is implemented in a relational database schema, the student object 550 is 
represented in a student table 552 that contains a student ID column and a name 
column. The multi-valued nature of the major and year-data components means that 
these attributes must be defined as separate child tables 554, 556. Both of these child 
tables 554, 556 are related to the student table 552 through a foreign key student field, 
and both contain a surrogate primary key value. The year-data table 554 contains a year 
column and a GPA column, while the major table 556 contains only one data column 
(major). Figure 12a shows the situation where a user changes student object 550 so that 
the major is not a separate, multi-valued component, but instead is a single-valued field 
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that is part of the year-data group. Kawai, col. 20, lines 48-53. When this occurs, the 
column that stores the student's major is moved from table 556 into table 554, as shown 
in Figure 12a of Kawai. 

The office action asserts that Figure 12a of Kawai teaches a plurality of data cells. 
As explained above, Figure 12a is seen to show four different data constructs: semantic 
data object 550, and the three relational tables 552, 554, and 556 that implement object 
550. The office action is ambiguous as to which of these standard database constructs is 
considered to be a data cell, and in fact implies that the figure as a whole shows a data 
cell. To clarify that a data cell is a separate data construct, the applicant has amended 
claim 1 to require that the data cell be a data construct that contains a single element of 
data. Thus, it is inappropriate to look at the four separate data constructs in Figure 12a 
as together defining a data cell, because this would be inconsistent with the language of 
amended claim 1. Looking at the individual elements of Figure 12a, it is clear that the 
tables and objects of Kawai are not data constructs that contain a single element of data. 
The student object 550, as is typical of all data objects, can store multiple components or 
attributes (such as the student id, major, and year-data). Similarly, the tables of Kawai, 
like all database tables, contain multiple rows with each row having multiple columns 
of data. Thus, neither the student object 550 or the relational tables 552-556 are data 
constructs that contain a single element of data, and therefore do not constitute a data 
cell as defined by claim 1. 

A single row in "Major" table 556 comes closest to being a data cell, since each 
row in table 556 contains only a single real data or attribute value column ("Major"), 
along with a surrogate key (similar to an object identifier) and a foreign key column. 
However, a row is not a separate data construct, but merely a portion of a table 
construct. This is clearly the case when one realizes that a row cannot stand on its own. 
It is relevant only within the definition of a table, which indicates the type of 
information that is found within each row through its column definitions. 

But even if one assumes that a row in table 556 is a separate data construct (an 
assumption that the applicant rejects), that row would not meet the other requirements 
of the claims. Specifically, there is no attribute type identifier (as required by part ii of 
claim 1) in that row, and there is no entity identifier value (as required by claim 2) in 
that row. The specification states that the attribute type identifier indicates the type of 
information found in the cell, such as an employee name. Specification, page 8, lines 8-9; 
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page 3, lines 13-14. This is consistent with the limiting language of claim 1, wherein the 
attribute type identifier identifies "one specific attribute type for the specific entity 
type." The office action identifies the foreign key student of Figure 12a in Kawai as an 
attribute type identifier. The foreign key student column contains the foreign key that 
relates these tables 554, 556 with the parent table 552. See col. 5, line 60 to col. 6, line 2. 
These columns do not identify an attribute type, and hence are not attribute type 
identifiers. Furthermore, claim 1 requires that the "attribute value" be for the attribute 
type specified in the attribute type identifier. Assuming the value in the "Major" 
column to be the attribute value, it is clear that this value is not for the attribute type 
identified in the foreign key student column. 

Similarly, there is no entity identifier value in a row of table 556. The 
specification states the entity identifier value identifies the type of entity associated with 
a cell. Specification, page 7, lines 25-27. There is no such value in the rows of table 556. 
The office action cites "major fig. 12a, Kawai" as teaching this element. The applicant 
accepts that a "major" is a separate entity in the relational database constructs shown in 
Figure 12a. However, claim 2 does not simply require that an entity exist, but that each 
data cell contain an entity identifier value. As explained above, the entire of Figure 12a 
is not a cell data construct, but is in fact multiple constructs, namely an object construct 
and three table constructs. None of these constructs contain a single element of data, 
except a row in table 556, and that row does not have an entity identifier value. 

The office action then states that the limitation in claim 3, namely identifying a 
cell set as a group of cells having the same instance identifier value and the same entity 
identifier value, is taught in object 100 of Figure 2. This figure shows a simpler example 
of the ability of the Kawai invention to alter a relational database schema upon a change 
to a semantic object. In this figure, an employee object 100 is altered by adding a single- 
valued "Birthday" component. Kawai, col. 5, lines 5-42. This is accomplished by adding 
a "Birthday" column 107 to the existing relational table 105 representing an employee. 
Kawai, col. 5, lines 23-33. There is no teaching of data cells, instance identifier values, or 
entity identifier values in Figure 2 or its corresponding text. Furthermore, nothing in 
Figure 2 teaches or suggests defining a cell set as all cells having the same instance 
identifier value and the same entity identifier value. 

As for claim 6, which requires that no two cells contain the same values in all of 
the four fields, the office action merely refers to table 105 and additional column 107 of 
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figure 2, and its corresponding text. The applicant could not find any such teaching, and 
respectfully requests a withdrawal of this rejection. 

Associating Data Cells (Claims 9, 12, 15-20) 

Claim 9 covers a method to establish an association between a first data cell and 
a second data cell by creating a third data cell formatted in the same way as the first and 
second data cells, with the third cell having the same entity instance identifying 
information as the first cell, and an attribute value that is the same as the entity instance 
identifying information of the second cell. The office action states that Figure 6 of Kawai 
anticipates this method. 

Figure 6 demonstrates how a database is modified when a user creates a 
parent/ subtype relationship between two objects. In Figure 6, a manager object 152 is 
changed by making it a subtype of an employee object 150. This causes the relational 
table 160 that represents the manager to be altered to include an additional column 162 
that contains a foreign key to the employee relational table 158. 

The office action asserts that the employee object 150 can be considered the first 
data cell, the manager object 152 is the second data cell, and that the social security 
number that exists within the employee object 150 is the third data cell. But this 
assertion is not consistent with claim 9 in several ways. First, the applicant notes that 
the creation of the third data cell in claim 9 is part of a method to establish an 
association between the first and second cells. The social security number in the 
employee object does not establish any association between the employee object and the 
manager object. Instead, the relationship between these objects is established by object 
link components 154 and 156. This relationship is duplicated in the employee and 
manager tables by the addition of social security number column 162 to the manager 
table 160. In neither instance does social security number that exists within the 
employee object 150 (the item identified in the office action as the third data cell) help 
establish an association. 

If we turn to the two methods that are used in Figure 6 for establishing a 
relationship, namely the object link components 154, 156 and the social security number 
column 162, we see that neither method uses any of the steps of claim 9, let alone all 
three steps. Step a) of claim 9 requires that the third data cell be formatted in the same 
way as the first and second data cells. The object link components 154, 156 are not 
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formatted in the same way as the objects 150, 152 that they relate. Similarly, while 
column 162 creates a relation between table 158 and table 160, column 162 is not 
formatted in the same way as either of these tables. 

Steps b) and c) of claim 9 define how the entity instance identifying information 
and the attribute value of this third cell establishes the relationship. This does not occur 
in Figure 6. Step b) requires "using the entity instance identifying information found in 
the first data cell as the entity instance identifying information of the third data cell." 
The office action asserts this is found in column 162. But the office action does not 
identify any value as the entity instance identifying information that is found in both 
one of the tables 158, 160 and in column 162. This is not surprising, because Figure 6 has 
no third cell formatted the same as the first two cells. Hence, there is no entity instance 
identifying information from a first cell that is used in the third cell, which is a 
requirement of step b). This is equally true of the object link components 154-156, 
neither of which is defined using entity instance identifying information and therefore 
cannot meet the requirements of step b). 

Finally, step c) of claim 9 requires that the entity instance identifying information 
of the second data cell be used as the attribute value for the third cell. The office action 
finds this in the use of the prod_group attribute in the manager object 152 as a column 
in the manager table 160. This assertion ignores the fact that the manager table is a 
simple implementation of the manager object under the invention of Kawai. Thus, the 
existence of the prod_group column in the manager table serves no function in 
associating two objects or tables together, but rather functions solely to realize the 
attributes of semantic object 152 in an actual, functioning relational schema. 
Furthermore, step c) of claim 9 requires the use of entity instance identifying 
information of a second data cell as the attribute value for a third cell. Nothing in 
Kawai, either in its description of this attribute or elsewhere, teaches that prod_group 
functions as entity instance identifying information within manager object 152, or that it 
functions differently (i.e., as an attribute value) within manager table 160. 

The applicant respectfully submits that the method of associating data cells in 
claim 9 is not found in Kawai, as none of the three steps of claim 9 are taught or 
suggested in Kawai. Claim 12 depends from claim 9, and adds a limitation that a fourth 
cell be formatted in the same way as the first, second, and third cells, with the fourth 
cell using the entity instance identifying information of the first and second cells as its 
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attribute value and entity instance identifying information, respectively. The office 
action asserts this is found in Figure 4 of Kawai, but Figure 4 adds nothing that was not 
found in Figure 6. Figure 4 simply shows the addition of a column 130 to a first table to 
establish a relationship to a second table, much like column 162 was added to a table in 
Figure 6. Thus, the same arguments made above for the patentability of independent 
claim 9 apply to the additional limitations of claim 12. 

Claim 15 defines a collection of data cells, with a first and second data cell each 
containing four fields, and a linking cell that defines an association between the first 
and second data cells. The linking cell is defined as having two of its four values being 
the same as two of the values in the first cell, with the remaining two values of the 
linking cells being the same as values in the second data cell. The office action states 
that this is found in Figure 4 of Kawai, with the secretary object 122 being the first cell, 
the manager object 120 being the second cell, and the linking cell being the object link 
component 118. 

The applicant does not agree with this assertion for several reasons. First, claim 
15 specifically states that each cell "contains a single element of data relating to a 
specific instance of an entity/ 7 As explained above in connection with claim 1, this 
limitation is not found in the cited objects 120, 122 or the object link component 118. 
Second, claim 15 requires each cell to have four fields, a limitation not shown in 
connection with objects 120, 122 or object link component 118. Finally, nothing in Kawai 
suggests that the object link component is created by having two of its four values being 
the same as two of the values in the first cell, with the remaining two values of the 
linking cells being the same as the second data cell. Consequently, the applicant 
suggests that none of these claim limitations is taught or suggested by Kawai, and claim 
15 should consequently be considered patentable. 

Claims 16 though 19 depend from claim 15, and further define the format of the 
cells. Claim 16 requires that the linking cell have the same format as the first and second 
cells, while claim 17 includes a requirement that the linking cell utilize a flag to indicate 
that the cell contains linking information. The limitations of claim 16 and 17 are clearly 
not found in the cited elements of Kawai, and are not found in the section of Kawai 
cited in the office action (col. 6, lines 37-46). Claim 18 defines the four fields of the cells 
as being an entity instance field, an entity type field, and attribute type field, and an 
attribute value field. The office action merely cites four attributes from Figure 4 (name, 
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address, salary, and wpm) as meeting this limitation. These attributes cannot be said to 
meet this limitation, as the field types of claim 18 clearly refer to the fields described in 
the specification, as explained in more detail above in connection with claims 1 and 2. 
Finally, claim 19 defines which two field types of the first cell and which two field types 
of the second cell make up the four field types in the linking cell. The office action cites 
col. 6, lines 51-62 and col. 7, lines 18-30 of Kawai as teaching this limitation. The 
applicant has examined the Kawai reference at these locations, and sees no particular 
relevance to the limitations of claim 19. The applicant respectfully requests that this 
rejection be withdrawn, or further explanation be provided. 

Finally, claim 20 depends from claim 19, and requires the creation of a second 
linking cell. The office action asserts that this is taught in col. 8, lines 47-60 in Kawai. 
This section in Kawai discusses an object link component that is used to link a professor 
object to a student object. The description and use of the object link component in this 
section of Kawai is no different than the object link components described above. Thus, 
for the same reasons described above, the applicant requests the withdrawal of this 
rejection. 

Rejection under 35 U.S.C. §103 

The Examiner has rejected claims 10, 11, 13, and 14 as being unpatentable over 
Kawai in view of Williamson, U.S. Patent No. 6,122,641. Claims 10, 11, 13, and 14 
depend from claim 9, and add still further details relating to the use of entity type 
information and / or attribute type in the three cells. The office action states that a) the 
use of entity type information in the first data cells as the entity type information of the 
third cell, and b) the use of the entity type information in the second data cell as the 
attribute type information of the third data cell were found in Williamson, specifically, 
item 478 of figure 4 and in column 6, lines 16-19. 

The applicant does not find any relevant teaching at column 6, lines 16-19. As for 
Figure 4, Williamson uses this figure to illustrate a portion of a relational database 
schema. Item 478 is illustrative of a join that can be made between an employee table 
402 and a projects table 442. In this Figure, an association between these tables 402, 442 
is made because the primary key of the employee table 402 (namely the Employee Id.) is 
used as a foreign key of the projects table 442. A similar situation exists in connection 
with join 470. In essence, Figure 4 of Williamson shows only what was shown in Figure 
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6 of Kawai, in which a foreign key column 162 is added to the manager table 160 that is 
the same as the primary key of the employee table 158. Nothing is described about 
using a third cell, formatted the same as the first and second cells, to form an 
association between the cells. Furthermore, nothing in Williamson or Kawai teaches or 
suggests using entity type information of the first cell as the entity type information of 
the third cell, or using the entity type information of the second cell as the attribute type 
information of the third cell. 

The applicant therefore respectfully submits that the additional limitations found 
in claims 10, 11, 13, and 14 are not found in or suggested by Kawai or Williamson, and 
these claims should be seen as patentable over the cited prior art. 

New claims 

The applicant has added new claims 21-23. These claims are supported by the 
specification as originally filed and are patentable over the cited prior art. 



All of the claims remaining in this application should now be seen to be in 
condition for allowance. The prompt issuance of a notice to that effect is solicited. 



CONCLUSION 
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